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DETAILED ACTION 

1 . This communication is in response to the amendment filed June 1 9, 2009. 

Status of Claims 

2. Claims 1 -2, 82 and 95 are amended. Claims 3-1 3, 15-19,21, 23-35 and 83-86 
are original. Claims 14, 20, 22, 91-94 and 96-97 are as previously presented. Claims 
36-81 and 97-90 are canceled. Claim 98 is new. Claims 1-35, 82-86 and 91-98 are 
pending. 

Claim Rejections - 35 USC §112 

3. The following is a quotation of the second paragraph of 35 U.S.C. 1 12: 

The specification shall conclude with one or more claims particularly pointing out and distinctly 
claiming the subject matter which the applicant regards as his invention. 

4. Claims 82-86 were previously rejected under 35 U.S.C. 112, second paragraph, 
as being indefinite for failing to particularly point out and distinctly claim the subject 
matter which applicant regards as the invention. In view of Applicant's amendments, 
the rejections are withdrawn. 

Claim Rejections - 35 USC § 103 

5. The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

6. Claims 1-11, 16, 18, 20, 21, 27-31, 82, 94-96 & 98 are rejected under 35 
U.S.C. 103(a) as being unpatentable by Mulinder et al., Pub. No. 2002/0073018 
(hereinafter Mulinder), in view of Garg et al., Pub. No. 2005/0021530 (hereinafter Garg). 
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As per claim 1, Mulinder teaches an automated brokerage system for 
processing activity requests related to financial instruments (See abstract, which 
discusses a system for real-time trading services), the system comprising: 

• a plurality of applications configured to generate activity requests related to 
one or more financial instruments in response to input from remote users 
(See 1J0009-001 1 , ^0043-0045, H0062, 1J0064 and Figs. 2, 5 and 5a, which 
discusses multiple applications/modules, including a price request 
application program interface (API) for trading securities); 

• a data source configured to provide financial instrument quote data, a data 
repository configured to store customer account data, and an order 
placement system configured to place one or more orders on a financial 
instrument trading market, the one or more orders being derived from at 
least one received activity request (See Abstract, 1T0024, 1T0043-0048, 
U0054-0055 and U0064; via quote engine, market maker, data storage 
system and trading system 21). 

Mulinder discloses that it would be obvious to one of ordinary skill to implement 
the disclosed invention in one or more computer programs that are executable on a 
programmable system including at least one programmable processor coupled to 
receive data and instructions from, and to transmit data and instructions to, a data 
storage system, at least one input device, and at least one output device 010064); 
however, Mulinder does not explicitly disclose a physical structure / architecture with the 
following elements: 
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• a front end layer comprising a plurality of applications configured to 
generate activity requests; 

• an intermediate layer in communication with the front end layer, the 
intermediate layer comprising a plurality of intermediate layer servers for 
simultaneously processing the generated activity requests, the 
intermediate layer servers being configured to provide a set of services in 
connection with the processing of the activity requests; and 

• a back end layer in communication with the intermediate layer. 

Garg teaches that a common architecture for a web service system is a tiered 
structure including a first tier of web servers (Applicant's front end layer), a second tier 
of application servers (Applicant's intermediate layer), and a third tier of database 
servers (Applicant's back end layer). Garg also teaches a method and apparatus for 
allocating resources to a plurality of applications. Garg teaches that servers of a data 
center may provide computational, storage, communications, or other basic services 
depending on application needs and data center priorities. Servers may be shared or 
dedicated to applications depending on resource requirements. For example, server 
1 1 2 may be shared by multiple applications 1 14, while server 1 1 6 may be dedicated to 
a single application 1 1 8 (Abstract, ^0003, 1(001 3-001 5 and Figs. 2-3). 

As stated above, Mulinder discloses that it would be obvious to one of ordinary 
skill to implement the disclosed invention in one or more computer programs that are 
executable on a programmable system including at least one programmable processor. 
And Garg teaches that a common architecture for a data center providing services 
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based on requests from remote users is implemented via tier architecture in which 
servers may be shared or dedicated to applications depending on resource 
requirements. 

Therefore, it would have been obvious to one of ordinary skill in the art at the 
time of Applicant's invention to modify the real-time trading system as disclosed by 
Mulinder, with the tiered server architecture as disclosed by the Garg, since the claimed 
invention is a substitution of one known element for another (i.e. distributing computer 
programs to run on dedicated servers instead of one server), and one of ordinary skill in 
that art would have recognized that the results of the substitution were predictable. See 
MPEP 2143 (Rev. 6, Sept. 2007), Rational (B). 

In addition, the known work in the field of data network designs (e.g. tiered 
architecture) could have prompted variations of it for use in either the same field or a 
different one based on design incentives or other market forces, and the variations 
would have been predictable to one of ordinary skill in the art. See MPEP 2143 (Rev. 6, 
Sept. 2007), Rational (F). 

In regards to the following element: 

• wherein the intermediate layer servers are configured to interact with the 
back end layer data source, the back end layer data repository, and the 
back end layer order placement system as necessary to process the 
received activity requests. 
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As stated above, Garg teaches that a common architecture for a web service 
system includes a second tier of application servers is in communication with a third tier 
of database servers. 

Mulinder discloses a system in which one or more computer programs that are 
executable on a programmable system including at least one programmable processor 
coupled to receive data and instructions from, and to transmit data and instructions to, a 
data storage system, at least one input device, and at least one output device. Mulinder 
also discloses quote engine 9' that receives (1) price quotes for derivatives from a 
market maker 10' and (2) real-time market information, such as spot price information 
and interest rate information, from a real-time market information source 11' (H0048). If 
and when a client requests a trade by invoking a request trade API that includes the 
parameters of the price quote, a flow manager T receives the trade request and 
forwards the trade to risk management and trading systems 21' for processing (1T0048, 
H0054-0055, 1J0064 and Figs. 1 , 2 and 2a). (Note: Mulinder discloses, at a minimum, 
five (5) systems performing five different functions: quote engine, market marker, real- 
time market information source, risk management system and a trade settlement 
system). 

It would have been obvious to one of ordinary skill in the art at the time of 
Applicant's invention to implement the real-time trading system as disclosed by Mulinder 
within a tiered architecture as taught by Garg to provide a communication structure in 
which applications are assigned subset(s) of resources based on application resource 
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requirement(s), maintaining a minimization of communication delays between 
resources, and a bandwidth capacity requirement(s) of the applications (Abstract). 

In addition, the known work in the field of data network designs (e.g. tiered 
architecture) could have prompted variations of it for use in either the same field or a 
different one based on design incentives or other market forces, and the variations 
would have been predictable to one of ordinary skill in the art. See MPEP 2143 (Rev. 6, 
Sept. 2007), Rational (F). 

As per claim 2, Mulinder does not disclose the following limitation; however, this 
limitation is taught by Garg: 

• wherein the intermediate layer servers comprise a plurality of dedicated 
servers, each dedicated server being configured to provide a different set 
of services in connection with the processing of the activity requests 
(Abstract, ^0003, ^001 3-001 5 and Figs. 2-3). Also see the rejection of 
claim 1. 

As per claim 3, Mulinder discloses the following limitations: 

• at least one order server configured to receive and process order activity 
requests (H0012, 1J0044, H0048, H0054-0055, 1J0064 and Figs. 2 and 2a; 
via forward the trade to a trade settlement system 21' for processing); 

• at least one customer account server configured to receive and process 
customer account activity requests (U0013, H0044, H0048, U0054-0055, 
110064 and Figs. 2, 2a and 5; via a client requests a trade by invoking a 
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request trade API that includes the parameters of the price quote, a flow 
manager 7' receives the trade request), and 

• at least one quote server configured to receive and process quote activity 
requests, wherein the processing of quote activity requests includes 
interacting with data source to retrieve the financial instrument quote data 
therefrom and providing the retrieved financial instrument quote for display 
to the users fl[001 1-0013, 1J0043-0044, U0048, U0054-0055, H0064 and 
Figs. 2 and 2a; via quote engine 9'). 

As stated above, Mulinder discloses a system in which one or more computer 
programs that are executable on a programmable system including at least one 
programmable processor coupled to receive data and instructions from, and to transmit 
data and instructions to, a data storage system, at least one input device, and at least 
one output device. As interpreted by the Examiner, the one or more computer programs 
include the quote engine, the modules and managers as illustrated in Fig. 2; and the 
programmable system including at least one programmable processor includes multiple 
processors (i.e. multiple servers). 

Therefore, Mulinder discloses the functional elements of the claim, but not the 
elements directed to the physical structure / architecture which include: 

• front end layer, 

• wherein the processing of customer account activity requests includes 
interacting with the back end layer data repository to retrieve customer 
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account data therefrom and providing the retrieved customer account data 
to the front end applications for display to the users 

• back end layer, and 

• front layer applications. 

Garg teaches that a common architecture for a web service system is a tiered 
structure including a first tier of web servers (Applicant's front end layer), a second tier 
of application servers (Applicant's intermediate layer), and a third tier of database 
servers (Applicant's back end layer). Garg also teaches a method and apparatus for 
allocating resources to a plurality of applications. Garg teaches that servers of a data 
center may provide computational, storage, communications, or other basic services 
depending on application needs and data center priorities. Servers may be shared or 
dedicated to applications depending on resource requirements. For example, server 
1 1 2 may be shared by multiple applications 1 14, while server 1 1 6 may be dedicated to 
a single application 118 (Abstract, 1J0003, 1f0013-0015 and Figs. 2-3). Also see the 
rejection of claim 1 above. 

It would have been obvious to one of ordinary skill in the art at the time of 
Applicant's invention to modify the real-time trading system as disclosed by Mulinder, 
with the tiered server architecture as disclosed by the Garg, since the claimed invention 
is a substitution of one known element for another (i.e. distributing computer programs 
to run on dedicated servers instead of one server), and one of ordinary skill in that art 
would have recognized that the results of the substitution were predictable. See MPEP 
2143 (Rev. 6, Sept. 2007), Rational (B). 
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In addition, the known work in the field of data network designs (e.g. tiered 
architecture) could have prompted variations of it for use in either the same field or a 
different one based on design incentives or other market forces, and the variations 
would have been predictable to one of ordinary skill in the art. See MPEP 2143 (Rev. 6, 
Sept. 2007), Rational (F). 

As per claim 4, Mulinder teaches wherein the order server is further configured 
to interact with the customer account server to obtain customer account data therefrom 
(See 1J0050 and 1J0064, which discusses processing a transaction utilizing client 
account information and implementing the method via one or more computer programs 
that are executable on a programmable system including at least one programmable 
processor). Also see the rejection of claim 1 regarding the combined teachings of 
Mulinder and Garg. 

As per claim 5, Mulinder teaches wherein the order server is further configured 
to interact with the quote server to obtain financial instrument activity requests (See 
1J001 1-0013, U0043-0044 and Figs. 2 and 2a, which discusses and illustrates a trade 
settlement system for processing trades and a quote engine capable of providing a 
plurality of quotes, each of which has a specified duration, when processing a trade in a 
security). 

As per claim 6, Mulinder teaches wherein the intermediate layer further 
comprises a database schema configured to store data related to receive activity 
requests (See paragraph 13, 49, & 64, which discusses a conventional database 
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management system; and, furthermore, monitoring a clients trading patterns and market 
activity, thereby creating a client account). 

As per claim 7, Mulinder teaches wherein the database schema (See paragraph 
64, which discusses using a conventional database management system) comprises: 

at least one customer database for storing customer-specific data (See 
paragraphs 13, 43-44, 46, 49-50 and Fig. 1, which discusses monitoring a clients 
trading patterns, market activity and checking client's credit rating and collateral status 
with the financial institution operating system 1, thereby accessing a client account); 
and 

at least one order database for storing order-specific data (See paragraphs 12, 
44 & 64, which discusses processing a trade in a security). 

As per claim 8, Mulinder teaches wherein the database schema further 
comprises at least one trading administration database for storing administrative 
restrictions related to activity requests (See paragraphs 46 & 49, which discusses 
spread rules and dealer intervention rules). 

As per claim 9, Mulinder teaches wherein the database schema further 
comprises a plurality of the customers databases, a plurality of the orders databases, 
and a plurality of the trading administration databases (See paragraphs 12, 13, 44, 49, 
& 64, which discusses a conventional database management system; and, furthermore, 
monitoring a clients trading patterns and market activity, thereby creating a client 
account, when processing a trade in a security). 
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As per claim 10, Mulinder teaches an administrator interface for controlling the 
content of the trading administration database (See paragraphs 44 & 54, which 
discusses a flow manager who coordinates and processes trades). 

As per claim 11, Mulinder teaches wherein the administrator interface is 
configured to provide an administrator with control over restrictions on at least one of 
the group consisting of a financial instrument-specific basis, a trading market-specific 
bases, and an option-specific basis (See paragraphs 44 & 54 which discusses a flow 
manager who coordinates and processes trades based on risk analysis and market 
volatility). 

As per claim 16, Mulinder teaches wherein the customer account server include 
memory resident thereon for storing customer account data that has previously been 
retrieved from the back end data repository (See paragraphs 13, 43, & 49, which 
discusses monitoring a clients trading patterns and market activity, thereby creating a 
client account; and, furthermore, a communication server that manages access to 
trading date; it is inherent the system contains memory), and wherein the customer 
account server is further configured to utilize the customer account data that has been 
stored in the resident memory according to predetermined criteria when processing 
customer account activity requests (See paragraphs 49 & 50, which discusses client 
information in relation to dealer intervention rules, including credit related factors). 

Claim 18 recites equivalent limitations to claim 16 and is therefore rejected using 
the same art and rationale set forth above. 
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As per claim 20, Mulinder teaches wherein the front end layer and the 
intermediate layer communicate with each other according to the Internet Protocol Suite 
(TCP/IP) protocol (See paragraph 43, which discusses communications protocol, 
including the internet). 

Claim 21 recites equivalent limitations to claim 20 and is therefore rejected using 
the same art and rationale set forth above. 

As per claim 27, Mulinder teaches wherein the back end data source comprises 
at least one quote feed, the at least one quote feed providing quote data in a data 
format to the quote server, and wherein the quote server is further configured to convert 
the received quote data to an internal data format upon receipt thereof (See paragraphs 
11-13, 43-44, & 46 which discusses a quote engine capable of proving a plurality of 
quotes, each of which has a specified duration; and, furthermore, utilizing a number of 
factors when describing price quote generation). 

As per claim 28, Mulinder teaches wherein the back end data source comprises 
a plurality of quote feeds, at least two of the quote feeds providing quote data in 
different data formats, and wherein the quote server is further configured to convert 
quote data received from each of the quote feeds to the internal data format upon 
receipt thereof (See paragraphs 11-13, 43-44, & 46, which discusses a quote engine 
capable of providing a plurality of quotes, each of which has a specified duration; and, 
furthermore, utilizing a number of factors when describing the price quote generation 
factor). 
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As per claim 29, Mulinder teaches wherein the quote data comprises a plurality 
of quote data types (See paragraphs 11-13 & 43-44, which discusses a quote engine 
capable of providing a plurality of quotes, each of which has a specified duration), and 
wherein the system further comprises an administrator interface configured to select, in 
response to administrator input, which of a plurality of quote feeds are to be used for 
receiving each of the plurality of quote data types (See paragraph 44, which discusses 
how a dealer intervention module may be used by a trader to control the pricing and 
trading activity). 

As per claim 30, Mulinder teaches wherein the back end layer further comprises 
a plurality of the data repositories, and wherein the intermediate layer servers are 
configured to interact with both the back end data repositories when processing activity 
requests (See paragraph 64, which discusses using a conventional database 
management system). 

As per claim 31, Mulinder teaches an approval desk interface configured to 
provide a person with control over whether to approve or reject order activity requests 
routed thereto, and wherein the order server is further configured to determine whether 
an activity request is to be routed to the approval desk (See paragraph 51 , which 
discusses how the trader may reject or modify the price request). 
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As per claim 82, Mulinder discloses a method for processing activity requests 
related to financial instruments, the method comprising: 

• an automated financial instrument brokerage system (See Abstract and 
Figs. 1 and 2, which discusses and illustrates a system for real-time 
trading services); 

• providing a plurality of heterogeneous applications that are configured to 
generate activity requests related to financial instruments in response to 
user input (See ^0009-001 1 , U0043-0045, H0062, 1J0064 and Figs. 2, 5 
and 5a, which discusses multiple applications/modules, including a price 
request application program interface (API) for trading securities). 

Mulinder discloses that it would be obvious to one of ordinary skill to implement 
the disclosed invention in one or more computer programs that are executable on a 
programmable system including at least one programmable processor coupled to 
receive data and instructions from, and to transmit data and instructions to, a data 
storage system, at least one input device, and at least one output device (U0064); 
however, Mulinder does not explicitly disclose the following elements: 

• providing a first layer and a second layer, the first layer for interacting with 
users to generate activity requests, wherein the second layer is in 
communication with the first layer, and wherein the second layer is 
configured to process activity requests; 

• providing a common interface for each of the heterogeneous applications 
to communicate the activity requests to the second layer; 
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• receiving activity requests at the second layer from the common 
interfaces; and 

• processing activity requests in the second layer independently of the 
application from which those activity requests originated. 

Garg teaches that a common architecture for a web service system is a tiered 
structure including a first tier of web servers (Applicant's front end layer), a second tier of 
application servers (Applicant's intermediate layer), and a third tier of database servers 
(Applicant's back end layer). Garg also teaches a method and apparatus for allocating 
resources to a plurality of applications in which instrumentation is gathered for work 
requests to be processed by the applications. Garg teaches that servers of a data center 
may provide computational, storage, communications, or other basic services depending 
on application needs and data center priorities. Servers may be shared or dedicated to 
applications depending on resource requirements. For example, server 112 may be 
shared by multiple applications 114, while server 116 may be dedicated to a single 
application 118 (Abstract, U0003, H0013-0015 and Figs. 1-3). 

As stated above, Mulinder discloses that it would be obvious to one of ordinary 
skill to implement the disclosed invention in one or more computer programs that are 
executable on a programmable system including at least one programmable processor. 
And Garg teaches that a common architecture for a data center providing services 
based on requests from remote users is implemented via tier architecture in which 
servers may be shared or dedicated to applications depending on resource 
requirements. 
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Therefore, it would have been obvious to one of ordinary skill in the art at the 
time of Applicant's invention to modify the real-time trading system as disclosed by 
Mulinder, with the tiered server architecture as disclosed by the Garg, since the claimed 
invention is a substitution of one known element for another (i.e. distributing computer 
programs to run on dedicated servers instead of one server), and one of ordinary skill in 
that art would have recognized that the results of the substitution were predictable. See 
MPEP 2143 (Rev. 6, Sept. 2007), Rational (B). 

In addition, the known work in the field of data network designs (e.g. tiered 
architecture) could have prompted variations of it for use in either the same field or a 
different one based on design incentives or other market forces, and the variations 
would have been predictable to one of ordinary skill in the art. See MPEP 2143 (Rev. 6, 
Sept. 2007), Rational (F). 

As per claims 94-96, Mulinder does not explicitly disclose the following elements 
however, these elements are disclosed by Garg: 

• wherein the front end layer comprises at least one front-end server, the at 
least one front-end server being configured to execute the plurality of 
applications (Abstract, ^0003, 1J0013-0015 and Figs. 2-3); 

• wherein the at least one front-end server is further configured to distribute 
activity requests to the plurality of intermediate layer servers based an 
activity request type (Abstract, 1f0003, H0013-0015 and Figs. 2-3); and 
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• wherein the customer account server comprises a web-to-back office 
(WBO) server that acts as a gateway between the back end layer of the 
system and a customer using a website provided by the front end layer. 

As per claim 98, the combination of Mulinder and Garg disclose the following 
elements: 

• wherein the second layer comprises a plurality of dedicated servers, at 
least one of the dedicated servers being configured to receive and 
process activity requests from the first layer, at least one of the dedicated 
servers being configured to receive and process activity requests from the 
first layer, and at least one of the dedicated servers being configured to 
receive and process activity requests from the first layer (Garg: Abstract, 
H0003, H0013-0015 and Figs. 2-3); 

• wherein the activity requests are order activity requests (Mulinder: 1J0044; 
via receiving price request from client), quote activity requests (Mulinder: 
1J0044; via providing price quote to clients) and customer account activity 
requests (Mulinder: 1J0050; via checking credit rating and collateral status 
with the financial institution), 

• wherein the activity request processing step comprises interacting with a 
data repository and data source (Mulinder: H0048, U0054-0055, H0064; via 
database and real-time market information source), 
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• that are in communication with the second layer (Mulinder: 110064; via 
computer programs and processors; combined with Garg: Abstract, 
U0003, H0013-0015 and Figs. 2-3), 

the method further comprising: 

• routing generated activity requests through the common interface from the 
first layer to an appropriate one of the second layer dedicated servers 
based on a type for the generated activity request (Garg: Abstract, 1J0003, 
H0013-0015and Figs. 2-3). 

7. Claims 12-15 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Mulinder and Garg as applied to claim 3 above, and further in view of Bowman-Amuah, 
Pat. No. 6,578,068 (hereinafter Bowman-Amuah). 

As per claim 12, Mulinder teaches wherein the intermediate layer further 
comprises: a plurality of the order servers (See paragraphs 12 & 44, which discusses 
processing a trade in a security; and trade settlement system). 

However, Mulinder does not disclose a load balancer that interfaces with the 
front end applications with the plurality of order servers, the load balancer being 
configured to distribute order activity requests among the plurality of order servers. 

Bowman-Amuah discloses a system and method for distributing information 
amongst a client and server components for optimizing usage of resources. 

Both Mulinder and Bowman-Amuah disclose methods and systems for 
distributing information within a trading or ordering contexts. Bowman-Amuah discloses 
a load balancer that mediates the request, otherwise known as workload balancing (See 
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figure 151 and column 98, lines 22-49, which discusses how load balancing functionality 
effectively reduces the number of connections to databases, conserves the resources of 
the data servers, and increases throughput of the system). Therefore, it would have 
been obvious to someone of ordinary skill in the art at the time the invention was made 
to modify Mulinderto include a load balancer capable of distributing ordering activity 
requests over a plurality of servers as taught by Bowman-Amuah in order to combine 
the known features of trading systems and load balancing to achieve the predictable 
result of utilizing load balancing in a trading system to conserve resources and increase 
throughput. 

As per claim 13, Mulinder teaches wherein the intermediate layer further 
comprises: a plurality of the customer account servers (See paragraph 13 & 49, which 
discusses monitoring a client's trading patterns and market activity, thereby creating a 
client account; and credit module, computer programs, and processors 1T0064). 

However, Mulinder does not disclose a load balancer that interfaces the front end 
applications with the plurality of customer account servers, the load balancer being 
configured to distribute customer account activity requests among the plurality of 
customer account servers. 

Bowman-Amuah discloses a load balancer that mediates the request, otherwise 
known as workload balancing (See figure 151 and column 98, lines 22-49, which 
discusses how load balancing functionality effectively reduces the number of 
connections to databases, conserves the resources of the data servers, and increases 
throughput of the system). Therefore, it would have been obvious to someone of 
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ordinary skill in the art at the time the invention was made to modify Mulinder to include 
a load balancer capable of distributing customer activity requests over a plurality of 
servers as taught by Bowman-Amuah in order to combine the known features of trading 
systems and load balancing to achieve the predictable result of utilizing load balancing 
in a trading system to conserve resources and increase throughput. 

As per claim 14, Mulinder teaches wherein the intermediate layer further 
comprises: a plurality of the quote servers (See paragraph 1 1-13 & 43-44, which 
discusses a quote engine capable of providing a plurality of quotes, each of which has a 
specified duration; and processors 1f0064). 

However, Mulinder does not disclose a load balancer that interfaces with the 
front end applications with the plurality of quote servers, the load balancer being 
configured to distribute quote activity requests among the plurality of quote servers. 

Bowman-Amuah discloses a load balancer that mediates the request, otherwise 
known as workload balancing (See figure 151 and column 98, lines 22-49, which 
discusses how load balancing functionality effectively reduces the number of 
connections to databases, conserves the resources of the data servers, and increases 
throughput of the system). Therefore, it would have been obvious to someone of 
ordinary skill in the art at the time the invention was made to modify Mulinder to include 
a load balancer capable of distributing quote activity requests over a plurality of servers 
as taught by Bowman-Amuah in order to combine the known features of trading 
systems and load balancing to achieve the predictable result of utilizing load balancing 
in a trading system to conserve resources and increase throughput. 
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Claim 15 recites equivalent limitations to claims 12-14, respectively, and is 
therefore rejected using the same art and rationale set forth above. 
8. Claims 17, 19, 22-26, 83-86 & 97 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Mulinder and Garg as applied to claims 3 and 16 above, and further 
in view of Official Notice. 

As per claim 17, Mulinder does not disclose wherein the resident memory is 
application-in-memory cache. 

The Examiner takes Official Notice that it is old and well known in the art to store 
memory on a cache. Therefore, it would have been obvious to a person of ordinary skill 
in the art at the time the invention was made to modify Mulinder to include storing 
memory on an application-in-memory cache in order to making accessing memory a 
faster process. 

Claim 19 recites equivalent limitations to claim 17 and is therefore rejected using 
the same art and rationale set forth above. 

As per claim 22, Mulinder does not disclose wherein a plurality of the front end 
applications are heterogeneous applications configured to communicate with the 
intermediate layer through a plurality of common component object model (COM) 
objects. 

Toffey discloses multiple heterogeneous applications, including a computer, 
telephone, and a personal digital assistant (PDA) (See paragraphs 60 & 68, which 
discusses executing trades via telephone, computer, or PDA). Therefore, it would have 
been obvious to one of ordinary skill in the art at the time the invention was made to 
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modify Mulinder to include a plurality of heterogeneous applications including a 
computer, a telephone, and a PDA as taught by Toffey in order to provide multiple 
applications for executing a financial trade. 

Furthermore, the Examiner takes Official Notice that it is old and well known in 
the art to use component object model to assemble programs or add functionality to 
existing programs. Therefore, it would have been obvious to a person of ordinary skill in 
the art at the time the invention was made to modify the Mulinder and Toffey 
combination to include a component object model in order to link programs and add 
functionality. 

As per claim 23, Mulinder teaches order activity requests stored on an order 
server (See paragraphs 12 & 44, which discusses processing a trade in a security). 

However, the Mulinder and Toffey combination does not disclose wherein the 
front layer COM objects include a COM object for communicating order activity requests 
to the order server. 

The Examiner takes Official Notice that it is old and well known in the art to use 
component object model to assemble programs or add functionality to existing 
programs. Therefore, it would have been obvious to a person of ordinary skill in the art 
at the time the invention was made to modify the Mulinder and Toffey combination to 
include a component object model that allows communication with order requests on an 
order server in order to link programs and add functionality. 

As per claim 24, Mulinder teaches wherein the intermediate layer further 
comprises at least one trading administration database for storing administrative 
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restrictions related to activity requests (See paragraphs 46 & 49, which discusses 
spread rules and dealer intervention rules). 

However, the Mulinder and Toffey combination does not disclose wherein the 
front end layer COM objects further include COM object for validating an order activity 
request against restrictions stored in the trading administration database prior to 
forwarding that order activity request to the order server. 

The Examiner takes Official Notice that it is old and well known in the art to use 
component object model to assemble programs or add functionality to existing 
programs. Therefore, it would have been obvious to a person of ordinary skill in the art 
at the time the invention was made to modify the Mulinder and Toffey combination to 
include a component object model capable of validating trade requests against 
intervention in order to link programs and add functionality. 

As per claim 25, Mulinder teaches customer account activity requests stored on 
a customer account server (See paragraphs 13, 43, & 49, which discusses monitoring a 
clients trading patterns and market activity, thereby creating a client account; and, 
furthermore, a communication server that manages access to trading services; it is 
inherent the system contains memory). 

However, the Mulinder and Toffey combination does not disclose wherein the 
front end layer COM objects further include a COM object for communicating customer 
account activity requests to the customer account server. 

The Examiner takes Official Notice that it is old and well known in the art to use 
component object model to assemble programs or add functionality to existing 
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programs. Therefore, it would have been obvious to a person of ordinary skill in the art 
at the time the invention was made to modify the Mulinder and Toffey combination to 
include a component object model that allows communication with customer account 
activity requests on an customer account server in order to link programs and add 
functionality. 

As per claim 26, Mulinder teaches quote activity requests stored on a quote 
server (See paragraphs 1 1-13 & 43-44, which discusses a quote engine capable of 
providing a plurality of quotes, each of which has a specified duration). 

However, the Mulinder and Toffey combination does not disclose wherein the 
front end layer COM objects further include a COM object for communicating quote 
activity requests to the quote server. 

The Examiner takes Official Notice that it is old and well known in the art to use 
component object model to assemble programs or add functionality to existing 
programs. Therefore, it would have been obvious to a person of ordinary skill in the art 
at the time the invention was made to modify the Mulinder and Toffey combination to 
include a component object model that allows communication with quote activity 
requests on an quote server in order to link programs and add functionality. 

Claims 83-86 recite equivalent limitations to claims 22-23 & 25-26, respectively, 
and are therefore rejected using the same rationale set forth above. 

As per claim 97, Mulinder teaches wherein the customer account server is 
further configured to (1 ) check the application-in-memory cache for fresh customer 
account data when processing an activity request before accessing the back end data 
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repository for such customer account data, (2) use the fresh customer account data to 
process that activity request if the fresh customer account data is present in the 
application-in-memory cache, and (3) access the back end data repository for such 
customer account data if fresh customer account data is not present in the application- 
in-memory cache (See figure 6, and paragraph 6, which illustrates and discusses 
processing a trade request; and, furthermore, how it is well know in the art to 
automatically update data or requests). 

9. Claims 32, 34 & 35, are rejected under 35 U.S.C. 103(a) as being unpatentable 
by Mulinder. 

As per claim 32, Mulinder et al. teaches an automated brokerage system (See 
abstract, which discusses a system for real-time trading services), the system 
comprising: 

a plurality of applications configured to generate activity requests related to one 
or more financial instruments in response to input from remote users, the activity 
requests comprising any of the group consisting of order activity requests, customer 
account activity requests, and quote activity requests (See paragraphs 9 & 45, which 
discusses multiple applications, including a price request application program interface 
for trading securities); 

at least one order server configured to process the order activity requests (See 
paragraphs 12 & 44, which discusses processing a trade in a security); 
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at least one customer account server configured to process the customer 
account activity requests (See paragraphs 13 & 49, which discusses monitoring a 
clients trading patterns and market activity, thereby creating a client account); 

at least one quote server configured to process the quote activity requests (See 
paragraphs 1 1 -1 3 & 43-44, which discusses a quote engine capable of providing a 
plurality of quotes, each of which has a specified duration); 

at least one quote data source in communication with the at least one quote 
server, the quote data source being configured to provide financial instrument quote 
data to the quote server (See paragraphs 1 1-13 & 43-44, which discusses a quote 
engine capable of providing a plurality of quotes, each of which has a specified duration, 
when processing a trade in a security); 

at least one data repository in communication with the at least one customer 
account server and the at least one order server, the data repository being configured to 
store customer account data and provide stored customer account data to the customer 
account server (See paragraphs 50 & 64, which discusses using a conventional 
database management system and processing a transaction utilizing client account 
information); and 

at least one order placement system in communication with the order server, the 
order placement system being configured to place one or more orders received from the 
order server on a financial instrument trading market, the one or more orders being 
derived from at least one order activity request (See figures 1 & 2, which illustrates the 
system for providing trading services). 
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Mulinder et al. discloses all the elements of the claimed invention, however, 
Mulinder et al. does not disclose utilizing multiple servers and a respective placement 
system. 

It would have been an obvious matter of design choice to include multiple 
servers: order server, customer server, quote server, and a placement system, since 
Applicant has not disclosed that adding an order server, customer server, quote server, 
and a placement system is for any particular purpose, and it appears that the invention 
would perform equally well with one server/system containing multiple applications. 
Furthermore, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made to modify Mulinder et al. to include multiple servers with multiple 
applications and data sources in order to allocate the tasks to various applications and 
servers to help reduce bandwidth bottlenecks and to help increase the benefits from 
economies of scale in addition to offering increased security, excellent data 
management, fast response, and room for expansion. 

Claim 34 recites equivalent limitations to claim 16, and is therefore rejected 
using the same art and rationale set forth above. 

As per claim 35, Mulinder teaches wherein the order server is further configured 
to, when processing order activity requests, generate quote activity requests for 
communication to the quote server, and wherein the quote server is further configured 
to provide quote data that has been obtained in response to the quote activity request 
received from the order server to the order server (See paragraphs 1 1-13 & 43-44, 
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which discusses processing a trade in a security requests and a quote engine capable 
of providing a plurality of quotes, each of which has a specified duration). 

10. Claim 33 is rejected under 35 U.S.C. 103(a) as being unpatentable over 
Mulinder as applied to claim 32 above, and further in view of Bowman-Amuah. 

Claim 33 recites equivalent limitations to claims 12-14 above, and is therefore 
rejected using the same art and rationale set forth above. 

11. Claims 91-93 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Mulinder as applied to claim 82 above, and further in view of Toffey, Pub. No. 
2004/0236668 (hereinafter Toffey). 

As per claims 91-93, Mulinder does not disclose the following: 

• wherein the plurality of heterogeneous applications comprises at least two 
selected from the group consisting of: a web site, a telephone, a 
touchtone telephone, a voice recognition application, a cell phone, a 
pager, a personal digital assistant, a computer, a Windows trading 
application server, and a Java trading application server; 

• wherein the plurality of heterogeneous applications comprises at least 
three selected from the group consisting of: a web site, a telephone, a 
touchtone telephone, a voice recognition application, a cell phone, a 
pager, a personal digital assistant, a computer, a Windows trading 
application server, and a Java trading application server; and 
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• wherein the plurality of heterogeneous applications comprises a web site, 
a cell phone, a personal digital assistant, a computer, a Windows trading 
application server, and a Java trading application server. 
Toffey discloses multiple heterogeneous applications, including a computer, 
telephone, and a personal digital assistant (PDA) (See paragraphs 60 & 68, which 
discusses executing trades via telephone, computer, or PDA). Therefore, it would have 
been obvious to one of ordinary skill in the art at the time the invention was made to 
modify Mulinder to include a plurality of heterogeneous applications including a 
computer, a telephone, and a PDA as taught by Toffey in order to provide multiple 
applications for executing a financial trade. 

Response to Arguments 

12. Applicant's arguments, see pgs. 13-21, filed June 10, 2009, with respect to the 
rejections of claims 1, 2, 3, 82, 91-93 & 98 under 35 U.S.C. § 103(a) have been fully 
considered and are persuasive. Therefore, the rejections are withdrawn. However, 
upon further consideration, new grounds of rejection have been applied based on the 
disclosures and teachings of Garg. 

Applicant's arguments (pgs. 13-21) are essentially directed to the following 
claimed elements: 

(a) a front end layer, an intermediate layer and a back end layer 

(b) applications distributed across separate dedicated servers 
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In Response to (a): Applicant's arguments are moot in view of the new grounds 
of rejection based on the disclosures and teachings of Garg. 

In Response to (b): The Examiner respectfully disagrees with Applications 
assertion (see pg. 21 ) that "Mulinder fails to disclose that these tasks should be 
distributed across separate dedicated servers. Instead, Applicant interprets 
Mulinder such that these tasks are different software modules executing on the 
same processor platform." 

Figure 2 illustrates a block diagram of the Mulinder invention, which 
comprising modules, managers, etc. However, Mulinder explicitly recites that 
the invention can be implemented in one or more computer programs that are 
executable on a programmable system including at least one programmable 
processor coupled to receive data and instructions from, and to transmit data and 
instructions to, a data storage system, at least one input device, and at least one 
output device. Mulinder also discloses alternate embodiments of the invention 
can be implemented in hardware, firmware or a combination of both hardware 
and software, as well as distributing modules and/or data in a different fashion 
(would) be apparent to those skilled in the art. A reasonable interpretation is that 
each of the managers/modules can be implemented in separate servers (i.e. 
1J0064 discusses various design choices for implementing the functional logic 
blocks of the invention). 
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13. Applicant's arguments (pg. 2) regarding claim 32 have been fully considered but 
they are not persuasive. See the response to (b) above. 

14. The rejections of claims 17, 19, 22-26 & 83-86 included a rejection based on 

Office Notice. MPEP 2144.03.C recites: 

If applicant does not traverse the examiner's assertion of official notice or 
applicant's traverse is not adequate, the examiner should clearly indicate in the 
next Office action that the common knowledge or well-known in the art statement 
is taken to be admitted prior art because applicant either failed to traverse the 
examiner's assertion of official notice or that the traverse was inadequate. If the 
traverse was inadequate, the examiner should include an explanation as to why it 
was inadequate. 

Accordingly, the Office Notice statements made by the previous Examiner in rejecting 
claims 17, 19, 22-26 & 83-86 in regards to "store memory on a cache" and "the use of 
component object model to assemble programs or add functionality to existing 
programs" as being old and well-known in the art has been taken to be admitted prior 
art because Applicant failed to traverse the Examiner's assertions. 

Conclusion 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to GREGORY JOHNSON whose telephone number is 
(571)272-2025. The examiner can normally be reached on Monday - Friday, 8:30AM - 
5:00PM. 
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If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, ALEXANDER KALINOWSKI can be reached on (571) 272-6771 . The fax 
phone number for the organization where this application or proceeding is assigned is 
571-273-8300. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 

/Alexander Kalinowski/ GREGORY JOHNSON 

Supervisory Patent Examiner, Art Unit 3691 Examiner, Art Unit 3691 



